Dynamic analysis and static analysis are two different techniques used in the automated testing of software code. Dynamic analysis is performed by observing the behavior of code while the code executes on a machine. Static analysis is performed on static code i.e., code that is not running during the analysis process.
Dynamic analysis evaluates runtime behavior of computer code. Instrumentation code is inserted into the code-under-test. The instrumentation code captures runtime information generated in the course of execution of the code for use in observing and evaluating the dynamic, i.e. runtime execution, behavior of the code. U.S. Pat. No. 5,335,344, invented by Hastings, discloses an example of some known software code instrumentation and dynamic analysis techniques. The execution of code during dynamic analysis is driven by tests, which are artifacts that provide input parameters to the system undergoing the analysis. Additionally, tests verify the intended behavior by comparing the output from the system under test with the expected output recorded as part of each test case.
Static analysis can be used to detect kinds of errors that are often missed when using dynamic analysis techniques alone. For example, static analysis may detect an illegal operation that is contained in a rarely traversed or otherwise hard-to-test conditional branch code path that is rarely visited during operation of the software, and that therefore, easily could go undetected during dynamic analysis. Static analysis ordinarily involves use of a variety of different static analysis programs/software tools often referred to as ‘checkers’ to evaluate code paths to identify different kinds of vulnerabilities and/or errors. For example, checkers can be used to detect syntax errors, functions without return values, variables that have been declared but not used, inadvisable automatic type conversions, tainted data, integer overflows, global-variable inconsistencies, problems associated with using modules (e.g., missing or invalid modules or input/export mismatches), to name just a few.
Dynamic analysis and static analysis techniques have been developed that utilize information generated during a build process to identify the code that is to be subjected to analysis. Modern software typically is developed using a modular approach. Teams of programmers may work on different modules or portions of the software. Consequently, source code, compilers, and ancillary software components often are distributed across many different directories and systems. As a result of this complexity, software developers typically use build management utilities such as the “make” program to assist in the process of building executable code.
Dynamic analysis and static analysis can take advantage of the build process by intercepting information about the code generated during a build process and using the information to identify the code to be analyzed. During a typical software development process, source code is compiled to produce an executable script in a high-level programming language, byte code that needs to be further interpreted by an interpreted program, and/or executable binary code that runs directly on the CPU. Different portions of the software may be written using different programming languages that require the use of different compilers, for example. Moreover, different compilers may be used to compile different portions of the source code, even when all of the code is written in the same language. For example, different compilers may produce executable code that runs on computer systems with different microprocessors. A ‘build’ process, which involves identifying the source code files associated with a program and establishing appropriate directory locations, compiler names, and other compilation settings involves many steps, and software developers typically automate such a build process using what typically is referred to as a build program. Both dynamic analysis and static analysis processes may leverage information about source code that is made available during the build process by intercepting information that identifies the code to be statically analyzed. Commonly owned U.S. Pat. No. 7,340,726 invented by Chelf et al. describes examples of some known static analysis techniques that leverage information about code made available during a build process.
Dynamic analysis can require a large amount of computing resources and can be time consuming. During a software development process, there may not be adequate computing resources or adequate time to run all possible tests. Therefore, there is a need to prioritize the tests such that higher priority tests run before lower priority tests.